This is a robot that moves in a true circle, radius 140, using Bresenham's integer circle algorithm (found on page 283 of the May 1990 BYTE magazine). It is composed of four movement control routines, one per quadrant (plus some quickie code that gets it to the middle of the left wall). I originally tried to do this with processor speed of 30 (right before the third RoboWar tournament was run) and developed a movement control loop that was exactly 30 instructions long. It's necessary to update both speedx and speedy _every_ chronon if you want to move in a circle when using Bresenham's algorithm, so this was a Good Thing.
Unfortunately something was wrong with the logic; the robot kept on migrating outside of the path of the circle. Basically, it was moving in a very gentle spiral; when it started out the first quadrant everything looked OK but it ended up in the wall by the time it was done with the first quadrant, having moved outside of the path that is a true circle. This put a damper on plans for usage of the robot, which were to use it as a target for the third RoboWar Tournament individual competition (to expand the number of robots in the individual competition to a multiple of 6, which makes inventing a schedule of group combats a lot easier). But robots which kill themselves don't do well, so David had to use Aeneas III and Freud to pad the rosters. I couldn't figure out what was wrong (neither could David) and the robot was put on the back burner.
It is now just after the Fourth RoboWar Tournament (in which Doug and I kicked some butt; two entries, two first places). I was reorganizing my robot collection into some semblance of order today, and noticed this one lying around. So I decided to finally get around to debugging it. I never have figured out what was wrong with the original version, though I did come to the conclusion that I was making the movement control routines needlessly complex. I simply wrote new control routines. The new routines vary from 26 to 28 instructions, depending on which quadrant you're talking about (exclusive of the sync instruction at the top of the loop and the stuff that rotates the turret and fires at things). Originally, this robot didn't shoot at all (30 instructions per chronon was barely enough for movement), but with 50 instructions per chronon, I have plenty for the bullet firing routine.
If you are totally mystified and don't have the aforementioned BYTE magazine to explain things better than I can, this is what the routines are doing: The robot "contemplates" moving to a point diagonal from its current position (for instance, in the upper left quadrant, it would consider the point x+1,y-1). Based on whether that point lies inside, outside, or exactly on the circle, and which quadrant the robot is in, the robot makes a decision about how it should move. Using the upper left quadrant as an example, the robot would move only in the y direction if the tested point was inside the circle, only in the x direction if the point was outside, and in both if the point was on the circle. (In all three cases, while the robot is in the upper left quadrant, it will move up if it moves in the y direction and right if it moves in the x direction.) Think about it, draw a diagram, and you should see why this works.
By now you've probably looked at the actual code and been shouting "WHAT THE *(*#@!@#^ IS HE TALKING ABOUT!!!" Relax, all I can say is that my code is very optimized, so it doesn't look much like the process I've described above. Unfortunately for you, if you can't figure out what I'm doing, I'm feeling far too lazy to actually type up a description of how my code works.
As I noted above, this isn't a terribly good motion routine for a combative robot. It has to move at a speed of 1 in each direction to work (any faster and the constant speed adjustments would cause the robot to run out of energy; I thought of using the move registers for movement but some quick mental arithemtic reveals that using them drains energy faster than it is regained even at movement increments of 1), and it eats up loads of processor time. It moves so slow that it takes about 900 chronons to travel one complete circle. (It's actually sort of boring to watch if you don't have a fast Mac.) Thus, if it had worked when I first tried to write it, it would have made a good sitting duck for the Third Tournament.
This code won't make its way into any Tournament robot (of mine anyway; feel free to steal it if you can't write your own and want something that isn't very competent).
